home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11234 < prev    next >
Encoding:
Text File  |  1996-08-05  |  1.3 KB  |  67 lines
  1. Path: sunb.ocs.mq.edu.au!pixel!eddyg
  2. From: marting@jtec.com.au (Martin Gregory)
  3. Newsgroups: comp.lang.c++,comp.object
  4. Subject: Style question: OOD & initialisation
  5. Date: 13 Mar 1996 07:47:18 GMT
  6. Organization: JTEC Pty Ltd Perth R&D Office
  7. Distribution: world
  8. Message-ID: <MARTING.96Mar13154718@igly.jtec.com.au>
  9. NNTP-Posting-Host: valhalla.mpce.mq.edu.au
  10.  
  11.  
  12. Suppose you have designed your system wonderfully in an OOD sort of
  13. sense.  It seems to me that this means you may well have ended up with
  14. some sort of 'agent' class which controls everything, and knows how to
  15. despatch activities.  The question in my mind is how should you
  16. instantiate this controller.  To me, this (at first) seemed elegant:
  17.  
  18.  
  19. class Controller
  20. {
  21. public:
  22.   Controller();
  23.   //...
  24. }
  25.  
  26. Controller::Controller()
  27. {
  28.  
  29.   Thingy Servant1, Servant2;
  30.  
  31.   // ... instantiate all the other things in the system, then...
  32.  
  33.   while (still_something_to_be_done)
  34.   {
  35.      // hand out stuff
  36.   }
  37. }
  38.  
  39. main()
  40. {
  41.   Controller TheController;
  42. }
  43.  
  44.  
  45. However, is this concept of a constructor that doesn't exit till the
  46. end of time a bit of a worry?  (I think it is at least valid.)
  47.  
  48. Would this type of thing be preferrable:
  49.  
  50. main()
  51. {
  52.   Controller TheController;
  53.  
  54.   TheController.Go();
  55. }
  56.  
  57. If so, why?
  58.  
  59. Cheers,
  60.  
  61. Martin.
  62.  
  63. (Responses emailed to me as well as posted would be much appreciated)
  64.  
  65.  
  66.  
  67.